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Abstract 

Lately we have seen how sandboxing technology is positively altering the software security landscape. From the 
Chrome browser, to Adobe Reader, to Mac and iOS applications, sandboxing has become one of the main exploit 
mitigation technologies that software has come to rely on. As with all critical security technologies, they need to 
be understood and scrutinized, mainly to see how effective they are, or at the very least, to satisfy one's curiosity. 
The sandbox implementations for Adobe's Flash Player certainly piqued ours. 

Our talk will explore the internals of three sandbox implementations for Flash: Protected Mode Flash for Chrome, 
Protected Mode Flash for Firefox, and Pepper Flash. And of course, we will show that an exhaustive exploration of 
the Flash sandboxes will eventually yield gold as we discuss and demonstrate some Flash sandbox escape 
vulnerabilities we found along the way. 

We start with a look at the high level architecture of each sandbox implementation. Here we will define the role of 
each process and the connections between them. In the second part, we will dive deep into the internal sandbox 
mechanisms at work such as the sandbox restrictions, the different IPC protocols in use, the services exposed by 
higher-privileged processes, and more. In the third part of our talk we will take a look at each sandbox's security 
and talk about the current limitations and weaknesses of each implementation. We will then discuss possible 
avenues to achieve a sandbox bypass or escape. Throughout all this we will be pointing out the various differences 
between these implementations. 
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2. Introduction 

During Black Hat USA last year, we gave a talk about Adobe Reader X's sandbox. In that talk we covered the 
sandbox implementation of one of the primary exploitation vectors used by malware. We also noted that ever 
since the Reader X sandbox's introduction there has been a remarkable decrease in PDF exploits released in the 
wild, and thankfully, this remains true up to this time. This year, we focus our sights on another popular 
exploitation vector - Adobe's Flash Player, and this time, we have three implementations of the sandbox to play 
with. 

In doing this research, we asked ourselves the same things we did last year. What are the security implications 
with this new technology and what other things can an attacker do in spite of the restrictions imposed by the 
sandbox? What can still be done within these limits that, from an attacker's perspective, would still bring profit, or 
from a user's perspective, should be watched out for? Since we are investigating three different Flash sandbox 
implementations, we also asked ourselves how these implementations differ from each other. 

To answer these questions, we dived deeply into the internals of the three Flash sandbox implementations. This 
paper documents our findings and discusses the internal mechanisms, limitations, and potential escape avenues 
for each sandbox implementation. We will also provide our thoughts and recommendations on the matter of 
sandbox security. 
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3. The Targets 

In this paper, we will discuss three different implementations of the Flash Player Sandbox. The targets are: 

1. Flash Player Protected Mode For Firefox 

2. Flash Player Protected Mode For Chrome 

3. Flash Player Protected Mode For Chrome Pepper 

Throughout this paper we will refer to them as Firefox Flash, Chrome Flash, and Pepper Flash, respectively. 

Firefox Flash, an NPAPI [1] plugin, was first released as a beta on February 2012, and was officially released in June 
2012. It is developed by Adobe in collaboration with Mozilla. It is based on the sandboxing code in Adobe Reader X, 
which we covered in our talk and paper [2] at Black Flat USA last year. Flence, there will be a lot of similarities 
between them. We will be using version 11.3.300.257 in this paper. 

Chrome Flash, also an NPAPI plugin, has been around since December 2010 and is a result of collaboration 
between Adobe and Google. It is the default Flash player in Chrome. We will be using the version bundled with 
Chrome 20.0.1132.47 in this paper. 

Pepper Flash is an implementation of Flash player using Google's Pepper Plugin API (PPAPI) [3]. It can be enabled 
through Chrome > Settings > Privacy > Content Settings > Plugins. The version covered in this paper is bundled with 
Chrome 20.0.1132.47 and is an experimental version. At the time of writing, Chrome Beta 21 has been released 
which includes Pepper Flash as the default Flash Player. 
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4. Sandbox Architecture 

This section discusses the general architecture of each of the sandbox implementations. More details will be 
provided in the subsequent sections. 

4.1. Flash Player Protected Mode For Firefox 


Flash Player Protected Mode For Firefox 
(Firefox Flash) 



The Flash Player Protected Mode for Firefox (Firefox Flash) sandbox configuration consists of the following 
components: 

• Firefox Browser Process (firefox.exe) - The main Firefox browser process (firefox.exe). It launches 
plugin_container.exe when a web page with Flash content is opened. 

• Plugin Container (plugin_container.exe) - facilitates communication between the Flash plugin process and 
the Firefox browser process. It is also responsible for launching the broker process. 

• Flash Broker Process ( FlashPlayerPlugin.exe ) - spawned by plugin_container.exe. It is responsible for 
setting up the sandbox restriction and policies, and also for spawning the sandbox process. It also hosts an 
IPC service to communicate with the sandbox process. 
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• Flash Plugin Process (FlashPlayerPlugin.exe) - The sandboxed Flash plugin process. It is responsible for 
parsing and rendering Flash content. 

The Firefox Flash sandbox is enabled by default but it can be disabled using the privacy and security configuration 
file for Firefox Flash [4]. This file, mms.cfg, should be placed in the following folder: 

• %WINDIR\System32\Macromed\Flash for 32-bit Windows or 

• %WINDIR\SysWow64\Macromed\Flash for 64-bit Windows 

To disable the protected mode, set the ProtectedMode option in mms.cfg to 0: 


ProtectedMode = 0 


mms.cfg is also used to set up a policy file, which contains whitelist policies to bypass some of the default 
restrictions in the sandbox. To enable the whitelist policy file, the ProtectedModeBrokerWhitelistConfigFile option 
should be set to 1: 


ProtectedModeBrokerWhitelistConfigFile = 1 


A policy file with the file name ProtectedModeWhitelistConfig.txt should be placed in 
%WINDIR%\System32\Macromed\Flash for 32-bit Windows and %WINDIR%\SysWow64\Macromed\Flash for 64- 
bit Windows. 

4.2. Flash Player Protected Mode For Chrome 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



The Flash Player Protected Mode for Chrome (Chrome Flash) sandbox configuration consists of the following 
components: 

• Chrome Browser Process (chrome.exe) - The main Chrome browser process. It launches the Flash broker 
process and the Flash plugin process when a web page with Flash content is opened. It also exposes some 
browser-related services that the Flash plugin process connects to. 

• Chrome Renderer Process (chrome.exe) - The renderer process for the page the Flash content is in. It also 
exposes browser-related services that the Flash plugin process connects to. 

• Flash Broker Process ( rundll32.exe, gcswf32.dll! Broker Main) - rundll32.exe is used to run gcswf32.dll's 
BrokerMain entry point, which act as the broker process. It also hosts Flash specific services for the Flash 
plugin process. 

• Flash Plugin Process ( chrome.exe, gcswf32.dll) - The sandboxed Flash plugin process. It is responsible for 
parsing and rendering Flash content. 
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4.3. Flash Player Protected Mode For Chrome Pepper 


Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 



Flash Player Protected Mode for Chrome Pepper (Pepper Flash) sandbox configuration consists of the following 
components: 

• Chrome Browser Process (chrome.exe) - The main Chrome browser process. It launches the Flash plugin 
process when a web page with Flash content is opened. It also exposes some browser-related services 
that the Flash plugin process connects to. 

• Chrome Renderer Process (chrome.exe) - The renderer process for the page the Flash content is in. It also 
exposes browser-related and Pepper services that the Flash plugin process connects to. 

• Flash Plugin Process ( chrome.exe, pepfloshployer.dll) - The sandboxed Flash plugin process. It is 
responsible for parsing and rendering Flash content 
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5. Sandbox Mechanisms 

After discussing the architecture of each Flash sandbox implementation, we will now dive deep into the internal 
mechanisms used by each Flash sandbox implementation. In this section, we will start with the discussion of the 
mechanisms used for sandboxing the Flash plugin process and then progressively move the discussion to the 
mechanisms used by the higher-privileged processes. 

5.1. Sandbox Startup Sequence 

In this section, we will discuss the steps each sandbox implementation takes when starting up. 

5 . 1 . 1 . Firefox Flash 

1. When a web page with Flash content is opened, plugin_container.exe is spawned. 

2. plugin_container.exe then spawns the broker process FlashPlayerPlugin_ll_3_300_257.exe. 

3. The broker process sets up the sandbox restrictions for the sandbox process: 

a. Sets the job level to JOB_RESTRICTED, but with the following restrictions unset: 

• JOB_OBJECT_UILIMIT_READCLIPBOARD 

• JOB_OBJECT_UILIMIT_WRITECLIPBOARD 

• JOB_OBJECT_UILIMIT_GLOBALATOMS 

b. Sets the token level. It sets up two tokens, the initial token and the lockdown token. Both tokens 
will be active when the sandbox process is started. The sandbox process requires a more 
privileged token during startup, as it needs to access resources that are otherwise inaccessible 
due to the sandbox. The initial token allows the sandbox process to temporarily have an 
elevated privilege. It is only valid for the initial thread the process started with and will be 
discarded later. Other threads will only be using the less privileged lockdown token. The token 
levels assigned to each tokens are: 

• Initial token - USER_RESTRICTED_SAME_ACCESS for Vista or later, otherwise 
USER_UN PROTECTED 

• Lockdown token - USER_LIMITED 

Refer to section 5.2.1 for more details about the token restrictions. 

c. Sets the integrity level. It will be set to INTEGRITY_LEVEL_LOW. 

d. Adds a DLL eviction policy, which lists DLLs that are suspected or known to cause a sandboxed 
process to crash. These DLLs will be unloaded by the sandbox. Refer to section 11.1 for the list 
of evicted DLLs in Flash Player Protected Mode for Firefox. 

4. The broker process sets up the sandbox policies, which are rules that describe exceptions from the 
restrictions imposed by the sandbox policy. 
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a. Sets up admin-configurable policies. The policy rules are read from a file named 
ProtectedModeWhiteList.txt located in %WINDIR%\System32\Macromed\Flash for 32-bit 
Windows, or %WINDIR%\SysWow64\Macromed\Flash for 64-bit Windows. 

b. Sets up hard-coded policies for file, named pipes, process, registry, sync objects, mutant, and 
section access. 

5. The broker process spawns the sandbox process in a suspended state. It will run the 
FlashPlayerPlugin_ll_3_300_257.exe executable, the same as the broker, but with the "- 
type=renderer" parameter. 


6. Set up and initialize interceptions on the sandbox process. Refer to section 5.3 for more details 
about the interceptions. 

7. Resume execution of the sandbox process. 

5 . 1 . 2 . Chrome Flash 

1. When a web page with Flash content is opened, the Chrome browser process spawns rundll32.exe to 
launch the broker process via the gcswf32.dllIBrokerMain entrypoint. 

2. The Chrome browser process sets up the sandbox policies for the Flash sandbox process: 

a. Sets the job level to JOB_UNPROTECTED 

b. Sets the token level to the following: 

• Initial token - USER_RESTRICTED_SAME_ACCESS 

• Lockdown token - USERJNTERACTIVE 

3. Sets the integrity level to INTEGRITY_LEVEL_LOW 

4. Adds a DLL eviction policy, which lists DLLs that are suspected or known to cause a renderer process 
to crash. These DLLs will be unloaded by the sandbox. Refer to section 11.2 for the list of evicted 
DLLs in Chrome. 

5. Adds a plugin DLL eviction policy, which lists DLLs that are suspected or known to cause a plugin 
process to crash. These DLLs will be unloaded by the sandbox. Refer to section 11.3 for the list of 
evicted plugin DLLs in Chrome. 

6. The Chrome browser process spawns the sandboxed Flash plugin process, which is chrome.exe with a 
" type=plugin " parameter and with gcswf32.dll loaded. This process is initially launched in a suspended 
state. 

7. Set up and initialize interceptions on the sandbox process. Refer to section 5.3 for more details 
about the interceptions. 

8. Resume execution of the sandboxed Flash plugin process. 
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5 . 1 . 3 . Pepper flash 

Pepper plugins run under Chrome's renderer so the same restrictions apply with a minor difference. 

1. When a web page with Flash content is opened, the Chrome browser process sets up the sandbox policies 
for the Pepper Flash plugin process: 

a. Sets the job level to JOB_LOCKDOWN 

b. Sets the token level to the following: 

• Initial token - USER_RESTRICTED_SAME_ACCESS for Vista or later, otherwise 
USER_UN PROTECTED 

• Lockdown token - USER_LOCKDOWN 

c. Sets the integrity level to INTEGRITY_LEVEL_UNTRUSTED 

d. Sets alternate window station and desktop 

e. Adds a DLL eviction policy, which lists DLLs that are suspected or known to cause a 
renderer process to crash. These DLLs will be unloaded by the sandbox. Refer to section 
11.2 for the list of evicted DLLs in Chrome. 

f. Add policy for Pepper plugin. This simply adds full access to named pipes that match the 
following pattern "\\.\pipe\chrome.*”. 

2. The Chrome browser process spawns the sandboxed Pepper Flash plugin process, which is chrome.exe 
with a " type=ppopi " parameter and with pepfloshployer.dll loaded. This process is initially launched in a 
suspended state. 

3. Set up and initialize interceptions on the sandbox process. Refer to section 5.3 for more details 
about the interceptions. 

4. Resume execution of the sandbox process. 

5.2. Sandbox Restrictions 

Sandbox restrictions are the mechanisms in place to run the sandboxed Flash plugin process in a confined 
environment. In case the sandboxed Flash plugin is compromised, sandbox restrictions will prevent malicious code 
from making persistent changes to the system, and depending on the sandbox restrictions and sandbox policies in 
place, will also prevent malicious code from accessing confidential information from the system. 

The sandbox restrictions in all Flash sandbox implementations are based on the Practical Windows Sandboxing 
recipe [5, 6, 7] which describes the use of the following Windows mechanisms for restricting the privileges and 
capabilities of a sandboxed process: 

• Restricted Tokens 

• Integrity Levels 

• Job Objects 
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• Alternate Desktop and Alternate Window Station 

5 . 2 . 1 . Restricted Tokens 

One of the fundamental ways to lower the privileges of a sandboxed process is by assigning it a restricted token 
[8]. In the case of Flash, the restricted token assigned to the sandboxed Flash plugin process is derived from the 
user's token and has the following restrictions set: 

• Deny-Only Security Identifiers (SIDs) - Only pre-selected SIDs are left enabled, all other SIDs are set to 
deny-only. This limits the number of securable resources the sandboxed Flash plugin can access and the 
type of access it can be granted. 

• Restricting SIDs - Adding pre-selected SIDs as restricting SIDs. This ensures that the sandboxed Flash 
plugin can only access securable resources which are also accessible to the pre-selected restricting SIDs. 

• Limited Privileges - Enabling only a very limited number of privileges so that the sandboxed Flash plugin 
process is limited to the types of system operations it can perform (e.g. shutting down the system and 
debugging programs). 

5 . 2 . 2 . Integrity Levels 

A Low or Untrusted integrity level [9] is also set in the token assigned to the sandboxed Flash plugin process so that 
write access to most securable resources will be denied since the majority of securable resources in a Windows 
system are assigned a Medium or a higher integrity level. This also mitigates shatter attacks [10] as lower-integrity 
processes are prevented from sending write-type messages to windows owned by higher-integrity processes. 

5 . 2 . 3 . Job Objects 

Additional restrictions are also enforced to the sandboxed Flash plugin process by associating it with a job object 
[11]. Examples of capabilities that can be restricted via job objects are access to the clipboard, modification to 
system settings and preventing the spawning of additional processes. 

5 . 2 . 4 . Alternate Window Station and Alternate Desktop 

By assigning the sandboxed Flash plugin process a separate window station and a separate desktop, it is isolated 
from windows in other desktops, and the clipboard and global atom table in other window stations - all of which 
are vectors for sandbox escape and/or information disclosure. Note that this is only effective if the token assigned 
to the sandboxed process is set up so that the sandboxed process does not have access to other window stations 
and desktops. 

5 . 2 . 5 . Sandbox Restrictions Comparison Table 

The comparison table below shows the sandbox restrictions in place in Chrome Flash, Firefox Flash and Pepper 
Flash. 


Restriction 

Chrome Flash 

Firefox Flash 

Pepper Flash 

Integrity Level 

Low 

Low 

Untrusted 


Restricted Token: • User's SID • User's SID • Logon SID 

Enabled SIDs • Logon SID • Logon SID 

(Deny-Only SIDs • Everyone • Everyone 

Exceptions) . Users . Users 
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• INTERACTIVE 

• Authenticated Users 

• INTERACTIVE 



Restricted Token: 

• Logon SID 

• Logon SID 

• 

NULL SID 

Restricting SIDs 

• Everyone 

• Everyone 




• RESTRICTED 

• RESTRICTED 




• Users 

• Users 




• User's SID 




Restricted Token: 

• Bypass traverse 

• Bypass traverse 

(None) 

Enabled Privileges 

checking 

checking 




Job Restrictions 

• Kill on job close 

• Kill on job close 

• 

Kill on job close 



• Spawning additional 

• 

Spawning additional 



processes 


processes 



• Desktop creation and 

• 

Desktop creation and 



switching via 


switching via 



CreateDesktopf) and 


CreateDesktopf) and 



SwitchDesktopf) 


SwitchDesktopf) 



• Modifying display 

• 

Modifying display 



settings via 


settings via 


ChangeDisplaySettingsf) 
Logging off, shutting 
down or restarting the 
system via 
ExitWindows() or 
Exi t Win do wsEx() 

Using USER handles 
owned by processes not 
associated with the job 
Changing system 
settings via 

System Para mete rslnfof) 


ChangeDisplaySettingsf) 
Logging off, shutting 
down or restarting the 
system via 
ExitWindows() or 
Exi t Win do wsEx() 

Using USER handles 
owned by processes not 
associated with the job 
Changing system 
settings via 

SystemParometersinfoO 
Kill on unhandled 
exception 

Read from the clipboard 
Write to the clipboard 
Accessing global atoms 






Alternate Window 

Station and Alternate 
Desktop 

No 

No 

Yes 


Based on the table above, Pepper Flash has the most sandbox restrictions in place while Chrome Flash has the 
least restrictions in place. Pepper Flash is also the only sandboxed Flash running as an Untrusted integrity process. 
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The restricted token assigned to Chrome Flash can still obtain read access to resources accessible to the Users 
group, the Everyone group, and any resource accessible via the user's SID, such as private user files located under 
the user's Documents folder. On the other hand, the restricted token assigned to Firefox Flash can also be used to 
obtain read access to resources accessible to the Users group and the Everyone group but it cannot be used to 
access resources that accessible via the user's SID. The restricted token assigned to Pepper Flash is the most 
restrictive and very limited to what resources it can access; it cannot even access resources accessible to the Users 
and the Everyone group. 

Lastly, Pepper Flash is the only sandboxed Flash that uses a separate window station and a separate desktop. 
Similar to Adobe Reader X, Firefox Flash mitigates attacks relating to shared desktop use (such as shatter attacks 
and DLL injection via SetWindowsHookEx()) via the other sandbox restrictions [12], primarily, via the USER handles 
( UILIMIT_HANDLES ) job restriction and by running as a Low integrity process. 

5.3. Interception Manager 

The purpose of the Interception Manager is to transparently forward API calls made by the sandboxed Flash plugin 
process to a higher-privileged process such as a browser or a broker process. 

Generally, an API call is forwarded to the broker/browser process because the API call failed due to the sandbox 
restrictions in place. The broker/browser process on the other hand, evaluates the request against the sandbox 
policies and decides if the call will fail or succeed. In the latter case, the broker/browser process will generally 
perform the API call on behalf of the sandboxed process. An API call may also be automatically forwarded to the 
broker process because it just needs to be executed in the context of the higher-privileged process. 

For Chrome Flash and Pepper Flash, the API calls are forwarded from the sandboxed Flash plugin process to the 
Chrome browser process via a Sandbox IPC connection (discussed in section 5.4.1) and are serviced by the Chrome 
Sandbox services hosted in the Chrome browser process (discussed in section 5.5.1): 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 
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For Firefox Flash, the API calls are forwarded from the sandboxed Flash plugin process to the Flash broker process 
via a Sandbox IPC connection and are serviced by the Firefox Flash broker services hosted in the Flash broker 
process (discussed in 5.5.5): 

Flash Player Protected Mode For Firefox 
(Firefox Flash) 



Forwarding API calls is done transparently via API interceptions (or API hooking) in the sandboxed process. 
Depending on the type of interception, the API interceptions are set early in the sandboxed process initialization or 
when the DLL where the API is located is mapped into the sandboxed process. 

5 . 3 . 1 . Interception Types 

The table below describes the different types of interceptions: 


Interception Type 

Constant 

Value 

Description 


INTERCEPTION_SERVICE_CALL 

1 

Interceptions of type INTERCEPTION_SERVICE_CALL are 
performed for NTDLL APIs. Interceptions are performed by 
the broker/browser process to the sandboxed process via 
WriteProcessMemoryQ when the sandboxed process is 
newly spawned but still in a suspended state. 



API Interceptions are done by patching the entry point of 
the API with a stub that starts with the following code 
sequence: 




MOV EAX,<ServiceID> 

1 
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MOV EDX,<ThunkCodeAddress> 
JMP EDX 


ThunkCodeAddress points to an allocated memory 
containing a thunk code that sets up the stack and for 
performing the actual control transfer to the interception 
handler. 


INTERCEPTION_EAT 2 Interceptions of type INTERCEPTION_EAT are done by the 

sandboxed process to itself and are performed when the 
target DLL is mapped into the sandboxed process. DLL 
mapping is monitored via the interception of 
NTDLL.DLL!NtMopViewOfSection(). 

As its name suggests, interceptions of type 
INTERCEPTION_EAT are performed by patching the entry 
of the API in the export address table of the DLL. 


INTERCEPTION_SIDESTEP 3 Interceptions of type I NTERCEPTION_SI DESTEP are 

performed by the sandboxed process to itself when the 
target DLL is mapped into the sandboxed process. 

Interceptions of type INTERCEPTION_SIDESTEP are 
performed by patching the API entry point with a JMP 
instruction that transfers control to the thunk code: 


JMP <ThunkCodeAddress> 
<original API code> 
<original API code> 

< . . . > 


INTERCEPTION_SMART_SIDESTEP 4 Appears to be currently unused, but Chrome's source code 

suggests that this interception type is similar to 
INTERCEPTION_SIDESTEP but with a different thunk code. 


INTERCEPTION_UNLOAD_MODULE 5 This is a special interception type for DLLs which should be 

restricted from being loaded on the sandboxed process. 
Based on Chrome's source code, the DLLs that are set to be 
unloaded are those that are suspected or known to crash 
the sandboxed process. 


Table 1. Interception Types. (Reference: http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/sandbox_types.h?view=markup) 

5.4. Inter-Process Communication 

Inter-process communication (IPC) is the mechanism that allows processes to communicate with each other. In the 
case of the Flash sandboxes, IPC is used between processes with different privilege levels and between processes 
with the same privilege level. This section describes the different IPC implementations used in the Flash 
sandboxes. 

5.4.1. Sandbox IPC 

Originally from the Chromium project, all Flash sandbox implementations use the Sandbox IPC for communication 
between lower-privileged and higher-privileged processes. 
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In Chrome Flash and Pepper Flash, the Sandbox IPC is mainly used for forwarding API calls from the sandboxed 
Flash plugin process to the Chrome browser process: 


Flash Player Protected Mode For Chrome 
(Chrome Flash) 
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Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 



In Firefox Flash, aside from being used for forwarding API calls from the Flash plugin process to the Flash broker 
process, it is also used for invoking additional services, such as launching the Flash Player settings manager, which 
are exposed by the Flash broker process: 
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Flash Player Protected Mode For Firefox 
(Firefox Flash) 


Firefox Browser Process 

(firefox.exe) 


API Call 




Plugin Container 

(plugin-container.exe, NPSWF32.DLL) 


API Call 





API Call 


API Call 
[Sandboxed] 


Operating 

System 


5.4.1.1. Implementation 

Sandbox IPC is accomplished by shared memory and synchronization between the processes is done via Windows 
event objects. 

To setup the Sandbox IPC connection, the Chrome browser process (in the case of Chrome Flash and Pepper Flash) 
or the Flash broker process (in the case of Firefox Flash) which hosts the IPC server creates a chunk of shared 
memory and uses the upper part of this shared memory for the Sandbox IPC. The browser/broker process then 
creates a duplicate of the handle to the shared memory and transfers the handle duplicate to the sandboxed Flash 
plugin process via a WriteProcessMemoryO call. The IPC client hosted in the sandboxed Flash plugin process uses 
the transferred handle duplicate to map the shared memory to its address space. 

5.4.1.2. Message Structure 
IPC Shared Memory Structure 

The overall structure of the Sandbox IPC shared memory is consists of a top level IPCControl structure which is 
divided into channel control (ChannelControl) structures and channel buffer (Actual Cal I Pa rams) structures. 

The format of the IPCControl structure is as follows: 


Offset 

Size/Type 

Name 

Description 

0x0000 

0x04/size_t 

channels_count 

Number of IPC channels. Currently, 7 for Chrome 

Flash and Pepper Flash and 15 for Firefox Flash. 

0x0004 

0x04/HANDLE 

server alive 

Mutex handle that will be used by the IPC client to 
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determine if the IPC server is still alive. 

0x0008 channels_count*0xl4/ 
ChannelControl 

channels 

Channel control structures for channels_count IPC 
channels. Contains the control data for each 

channel. 

? channels_count* 

kIPCChannelSize / 
ActualCallParams 

(channel buffers) 

Channel buffer structures for channel_count IPC 
channels. Contains the actual serialized parameters 
for the IPC call. Each structure is kIPCChannelSize 
bytes each. 



Currently, kIPCChannelSize is 0x400 bytes for 

Chrome Flash and Pepper Flash and 0x2000 bytes 
for Firefox Flash. 


Table 2. IPCControl Structure. (Reference: 

http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/sharedmem_ipc_client.h?view=markup) 

IPC Channel Control Structure 

To allow multiple IPC connections, the IPC shared memory is divided into multiple IPC channels. Each IPC channel 
has its own corresponding channel control structure which contains the control data for each channel. 

The format of the IPC channel control (ChcmnelControl) structure is as follows: 


Offset 

Size/Type 

Name 

Description 

0x0000 

0x04/size_t 

channel_base 

Offset (relative to the start of the IPC shared memory) of 
the corresponding IPC channel buffer for this channel. 

0x0004 

0x04/LONG 

state 

State of the IPC Channel: kFreeChannel (1), kBusyChannel 
(2), kAckChannel (3), kReadyChannel (4), 
kAbandonnedChannel (5). 

0x0008 

0x04/HANDLE 

ping_event 

Event handle used by the IPC client to notify the IPC 
server that an IPC message is ready in this channel. 

OxOOOC 

0x04/HANDLE 

pong_event 

Event handle used by the IPC client to receive 
notification from the IPC server that a response is 
already available in the IPC channel. 

0x0010 

0x04/uint32 

ipc_tag 

IPC Tag - a unique identifier that identifies what service 
the caller is requesting. 


Table 3. ChannelControl Structure. (Reference: 

http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/sharedmem_ipc_client.h?view=markup) 

IPC Channel Buffer Structure 

Each IPC channel has a corresponding IPC channel buffer which will contain the serialized IPC call parameters and 
IPC call results. 

The format of the IPC channel buffer ( ActuolCallPorams ) structure is as follows: 
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Offset 

Size /Type 

Name 

Description 

0x0000 

0x04/uint32 

tag_ 

IPC Tag - a unique identifier that identifies what service 
the caller is requesting. Same value as 
ChannelControl.ipc_tag. 




The IPC server uses this value along with the type_ field 

from the Paramlnfo structures to select the handler 

routine that will service the request. 




An example IPC tag would be the value 0x03 for a 
request on the broker/browser process to invoke 
NtCreoteFilef) on behalf of the sandboxed process. 

0x0004 

0x04 /uint32 

is_in_out_ 

Contains an in/out parameter. 

0x0008 

0x34/CrossCallReturn 

call_return 

IPC call result values filled out by the IPC server after 
servicing a request. 

0x003C 

0x04 /size _t 

params_count_ 

Number of parameters. 

0x0040 

0x0C*(params_count+l 

)/Paramlnfo 

param_info_ 

Parameter information structures for param_count _+1 

parameters. 



parameters_ 

Actual parameter data. These are the serialized IPC call 
parameters. Example parameters are the object name 
and access mask used for the IPC call for NtCreoteFile(). 


Table 4. ActualCallParams Structure. (Reference: 

http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/crosscall_params.h?view=markup) 


The porom_info_ field is an array of Paramlnfo structures which contains information about the type, size and 
offset (relative to the start of the IPC channel buffer) of each parameter. Note that poram_info_ has an extra 
element; the extra element is used to quickly get the total size (used part) of the IPC channel buffer because its 
offset- field points to the end of the used part of the IPC channel buffer. 

The format of the Paramlnfo structure is as follows: 


Offset 

Size (Type) 

Name 

Description 

0x0000 

0x04/ArgType 

type_ 

Parameter type: WCHAR_TYPE (1), ULONG_TYPE (2), 
UNISTR_TYPE (3), VOIDPTR_TYPE (4), INPTR_TYPE (5), 
INOUTPTR_TYPE (6), CHAR_TYPE (7, specific to Firefox 
Flash), REMOTEBUF_TYPE (8, specific to Firefox Flash) 

0x0004 

0x04/ptrdiff_t 

offset_ 

Offset of parameter data (relative to the start of the IPC 
channel buffer). 

0x0008 

0x04/size_t 

size_ 

Size of the parameter. 
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Table 5. Paramlnfo Structure. (Reference: http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/crosscall_params.h?view=markup) 

An interesting parameter type in Firefox Flash which is also found in Adobe Reader X [2] is REMOTEBUF_TYPE. 
REMOTEBUF_TYPE is a type that represents a buffer in a remote process, it has the following fields: 

• Offset 0: pid (4 bytes) - process ID of the process where the buffer is located. 

• Offset 4: address (4 bytes) - address of the buffer in the remote process. 

• Offset 8: size (4 bytes) - size of the buffer in the remote process. 

Return values from an IPC call are stored in the ActualCallParams.call_return field which in turn is a 
CrossCallReturn structure. 

The format of the CrossCallReturn structure is as follows: 


Offset 

Size/Type 

Name 

Description 

0x0000 

0x04/uint32 

tag 

IPC Tag. Should be the same value as 
ChannelControl.ipc_tag but is not really set. 

0x0004 

0x04/ResultCode 

call_outcome 

Result code of the IPC call: SBOX_ALL_OK (0) or 
non-zero if an error occurred (see ResultCode 

enum in 

http://src.chromium.Org/viewvc/chrome/trunk/s 

rc/sandbox/src/sandbox_types.h?view=markup). 

0x0008 

0x04/NTSTATUS, 

DWORD 

nt_status/win32_result 

Return value of an API call when executed on the 

broker/browser process. Used for API 
interceptions. 

OxOOOC 

0x04/HANDLE 

handle 

If the IPC call returns a handle, generally, the 
handle or the handle duplicate is stored here. 

0x0010 

0x04/uint32 

extended_count 

Number of extended return values. 

0x0014 

0x04*8/MultiType 

extended 

Array of 8 MultiType extended return values. 
MultiType is a union and its members are: 
unsignedjnt, pointer, handle or ulong_ptr. 


Table 6. CrossCallReturn Structure. (Reference: 

http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/crosscall_params.h?view=markup) 

IPC Shared Memory Illustration 

Below is an illustration of the Sandbox IPC shared memory structure and the substructures it contains: 
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Sandbox IPC Shared Memory 

I PC Shared Memory (IPCControl) 

0x00: channels_count 
0x04: server alive 

0x0008 IPC Channel 1 
IPC Channel 2 
IPC Channel n 
IPC Channel Buffer 1 
IPC Channel Buffer 2 
IPC Channel Buffer n 


IPC Channel Control (ChannelControl) 
0x00: channel_base 
0x04: state 
0x08: ping event 
OxOC: pong event 
0x10: ipc tag 


IPC Channel Buffer (ActualCallParams) 

/ \ 

Call Return (CrossCalReturn) 

0x00: tag_ 


0x00: tag 

0x04: is_in_out_ 


0x04: call_outcome 

0x08: call_return (CrossCallReturn) 


0x08: nt_status/win32_result 

0x3 C: params_count_ 


OxOC: handle 



0x10: extended_count 

param_info_ 1 (Paramlnfo) 


1 

0x14: extended[8] 


param_info_ n 
param_info_ params_count_+1 
parameters_ 1 (raw data) 

J parameters_ n 
parameters params count 


Parameter Info (Paramlnfo) 
0x00: type_ 

0x04: offset_ (raw data offset) 
0x08: size_ 


5.4.2. Chromium IPC 

Originally from the Chromium project, the Chromium IPC is another IPC implementation used by all Flash sandbox 
implementations. The Chromium IPC is not only used for communication between processes with different 
privileges but it is also used for communication between processes with the same privileges. 

In Chrome Flash and Pepper Flash, Chromium IPC is used by the sandboxed Flash plugin, the sandboxed Chrome 
renderer, and the Chrome browser process to communicate with each other: 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 
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In Firefox Flash, Chromium IPC is used by the plugin container process to communicate with the sandboxed Flash 
plugin, Flash broker, and the Firefox browser process: 

Flash Player Protected Mode For Firefox 
(Firefox Flash) 



5.4.2.1. Implementation 

On Windows, Chromium IPC is done via a named pipe. Chromium IPC pipes are named using the format 
“\\.\pipe\chrome.%channel_id %”. %channei_id% varies in format depending on the type of connection the 
Chromium IPC is used for. 

For setting up the Chromium IPC connection, the process hosting the IPC server generates a unique pipe name and 
creates the pipe. With the pipe name usually passed via command line switch, the other process hosting the IPC 
client then connects to the IPC server. 

Two detailed articles also covering the Chromium IPC is the Chromium IPC design document [13] and Azimuth 
Security's blog post " The Chrome Sandbox Part 2 of 3: The IPC Framework” [14] . 

Listeners 

The square boxes in the diagrams are the names of the Listener class 
(http://src.chromium.org/viewvc/chrome/trunk/src/ipc/ipc_listener.h?view=markup) that handles the IPC 
connection in each process. 

Listener classes have an OnMessageReceivedf) method which dispatches the IPC messages to the appropriate 
service handlers. There are also cases where the Listener class which handles the IPC connection do not process 
the IPC messages themselves but instead " routes” the IPC messages to instances of other Listener classes. 
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Chromium IPC messages which are processed by the Listener class that handles the IPC connection are called 
"control" messages while Chromium IPC messages which are routed to instances of other Listener class are called 
"routed" messages. Furthermore, for control messages, Listener classes that handles the IPC connection may also 
implement an OnControlMessageReceivedf) method which is specifically used for dispatching control messages. 

Message Filters 

Before the IPC messages are sent to a Listener class, the IPC messages may be first sent to a list of message filters 
(MessogeFilter, http://src. chromium. org/viewvc/chrome/trunk/src/ipc/ipc_channel_proxy.h?view=markup). 

Similar to the Listener doss, the MessogeFilter class also have an OnMessageReceivedf) method which dispatches 
the IPC message to the appropriate service handlers. 

Message Classes 

Creating and dispatching IPC messages is made simpler in Chrome because there are available macros that 
automatically build IPC message classes. The following is an example use of the IPC message class generation 
macro to generate the PpopiMsg_LoodPlugin message class: 


IPC_MESSAGE_CONTROLl(PpapiMsg_LoadPlugin, FilePath /* path */) 


The above line expands to an IPC::Messoge class definition in which the generated class contains the code to build 
and dispatch the IPC message. For sending an IPC message, the generated IPC message class can just be 
instantiated and the resulting class instance can be passed to Send(Message* message) methods: 


Send(new PpapiMsg^LoadPlugin(plugin_path_)); 


The macros related to IPC message class generation are: 

• IPC_MESSAGE_CONTROL* 

• IPC_MESSAGE_ROUTED* 

• IPC_SYNC_MESSAGE_CONTROL* 

• IPC_SYNC_MESSAGE_ROUTED* 


Message Dispatching 

To simplify dispatching of the IPC messages to the appropriate service handler routines, Listener classes use the 
previously discussed generated IPC message classes plus another set of Chrome macros on their 
OnMessogeReceivedf) or OnControlMessageReceivedf) method: 


bool PpapiThread::OnMessageReceived(const IPC::Messages msg) { 

IPC_BE GIN_ME S SAGE_MAP(PpapiThread, msg) 

IPC_MESSAGE_HANDLER(PpapiMsg_LoadPlugin, OnMsgLoadPlugin) 
IPC_MESSAGE_HANDLER(PpapiMsg_CreateChannel, OnMsgCreateChannel) 

IPC_END_ME S SAGE_MAP() 


The above code expands to a switch statement which uses the type field of the IPC message to dispatch the IPC 
message to the appropriate service handler: 


bool PpapiThread::OnMessageReceived(const IPC::Messages msg) { 
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typedef PpapiThread _IpcMessageHandlerClass; 

const IPC::Messages ipc_message_ = msg; 

bool msg_is_ok_ = true; 

switch (ipc_message_.type()) 

case PpapiMsg_LoadPlugin::ID: { 

msg_is_ok_ = PpapiMsg_LoadPlugin::Dispatch(&ipc_message_, this, this, 

&_IpcMessageHandlerClass::OnMsgLoadPlugin); 

} 

break; 

case PpapiMsg_CreateChannel::ID: { 

msg_is_ok_ = PpapiMsg CreateChannel::Dispatch(&ipc message , this, this, 

&_IpcMessageHandlerClass::OnMsgCreateChannel); 

} 

break; 


The Chromium macros related to Chromium IPC message dispatching are: 

• I PC_ BEG I N_ MESS A G E_ MA P_EX 

• IPC_BE G IN_ MESS A G E_ MA P 

• IPC_MESSAGE_HANDLER 

• IPC_ MESSAGE_ HA NDLER_ DE LA Y_ RE PL Y 

• IPC_MESSAGE_HANDLER_GENERIC 

• IPC_ RE PL Y_ HA NDLER 

• / PC_MESSAGE_UN HANDLED 

• IPC_MESSAGE_UNHANDLED_ERROR 

• IPC_ E ND_ MESS A G E_ MA P 

• / PC_ E ND_ MESS A G E_ MA P_ EX 


SA.2.2. Message Structure 
Chromium IPC Message Structure 

The structure of a Chromium IPC message is shown below. Note that the Chromium IPC message structure may 
vary depending on the operating system and build parameters. The structure shown below is based on release 
builds of Google Chrome for Windows. 


Offset 

Size/Type 

Name 

Description 

0x0000 

0x04/uint32 

payload_size 

Total size of the payload (i.e. IPC call parameters). 

0x0004 

0x04/int32 

routing 

Routing ID. For control messages, the value of routing ID 
is MSG_ROUTING_CONTROL (0x7FFFFFFF). For routed 
messages, routing ID is a value identifying the instance of 
the Listener class which the IPC message will be routed to. 

0x0008 

0x04/uint32 

type 

Message Type. A unique ID specifying the service to be 
invoked. The upper 16 bit of the type field is the service 
group (discussed below) while the lower 16 bits is a 
unique value within a particular service group. 

The service group part of the type field can be used to 
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identify the kind of service being invoked. For Chrome 
processes (which includes the Chrome Flash plugin and 
Pepper Flash plugin process), service group values can be 
derived from the IPCMessogeStort enum in 
http://src.chromium.org/viewvc/chrome/trunk/src/ipc/ip 
c_message_utils.h?view=markup. 

OxOOOC 

0x04/uint32 

flags 

Message Flags. The first 3 bits are for message priority: 
PRIORITY_LOW (1), PRIORITY_NORMAL (2), 

PRIORITY_HIGH (3). The rest of the bits are for flags: 
SYNC_BIT (0x0004), REPLY_BIT (0x0008), 

REPLY_ERROR_BIT (0x0010), UNBLOCK_BIT (0x0020), 
PUMPING_MSGS_BIT (0x0040), HAS_SENT_TIME_BIT 
(0x0080). 

0x0010 


payload 

Serialized IPC call parameters. The class responsible for 
serializing/deserializing basic types is the Pickle class 
(http://src.chromium.org/viewvc/chrome/trunk/src/base 
/pickle.h?view=markup). 




Complex types are serialized/deserialized by 
specializations of the struct template called PoramTraits. 
ParamTraits methods, on the other hand, invoke Pickle 
class methods to serialize/deserialize the basic types 
which the complex type is composed of. 


Table 7. Chromium IPC Message. (Reference: http://src.chromium.org/viewvc/chrome/trunk/src/ipc/ipc_message.h?view=markup) 


Chromium IPC Message Illustration 

Below is an illustration of the Chromium IPC message structure: 

Chromium IPC Message 

0x00: payload_size 
0x04: routing 
0x08:type 
OxOC: flags 

0x10: payload/parameters (pickled) 
parameter 1 
parameter 2 
parameter 3 
parameter n 


5.4.3. Simple IPC 

Chrome Flash additionally uses an IPC implementation called "Simple IPC" for communication between the Flash 
plugin process and the Flash broker process, it is mainly used by the Flash plugin process to invoke the Chrome 
Flash broker services (discussed in 5.5.3) exposed by the Flash broker process: 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



5.4.3.1. Implementation 

On Windows, Simple IPC is done via a named pipe. In Chrome Flash, Simple IPC pipes are named using the format 
"\\.\pipe\MocromedioKoppa.%flosh_broker_hex_pid %". 

For setting up the Simple IPC connection, the Flash broker process which hosts the IPC server creates the Simple 
IPC pipe. Then, using the Flash broker PID passed via the command line switch "-flash-broker-', the Flash plugin 
process which hosts the IPC client generates the Simple IPC pipe name and then uses it to connect to the IPC 
server. 

Simple IPC is developed by Google and its source can be found in the simple-ipc-lib project hosted in 
http://code.google.eom/p/simple-ipc-lib/. 

5.4.3.2. Message Structure 

Simple IPC Message Structure 

The structure of a Simple IPC message is as follows: 


Offset 

Size (Type) 

Name 

Description 

0x0000 

0x04/int32 

Start of Fleader Mark 

The value 'KROM'. 

0x0004 

0x04/int32 

Message ID 

A unique ID identifying the service to be invoked. 

0x0008 

0x04/int32 

Element Count 

Number of elements (i.e. IPC call parameters). 
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OxOOOC 

0x04/size_t 

Data Count 

Total size of the IPC message (in 4 bytes). Messages 
should be aligned by 4 bytes. 

0x0010 

0x04/int32 

Element[0].tag 

Element Tag (i.e. parameter type): TYPE_INT32 (0x01), 
TYPE_UINT32 (0x02), TYPE_LONG32 (0x03), 
TYPE_ULONG32 (0x04), TYPE_CHAR8 (0x05), 
TYPE_CHAR16 (0x06), TYPE_VOIDPTR (0x07), 
TYPE_NULLSTRING8 (0x08), TYPE_NULLSTRING16 
(0x09), TYPE_NULLBARRAY (OxOA), TYPE_STRING8 
(0x40000016), TYPE_STRING16 (0x80000017), 
TYPE_BARRAY (0x40000018) 

? 

0x04/int32 

Element[n].tag 


? 

0x04/int32 

Start of Data Mark 

The value 'MORK'. 



Element[0]. value 

Serialized element (parameter) value. 

? 


Element[n].value 



0x04/uint32 

End of Data Mark 

The value 'BANG'. 


Table 8. Simple IPC Message Structure. (Reference: http://code.google.eom/p/simple-ipc-lib/source/browse/trunk/src/ipc_codec.h) 


Simple IPC Message Illustration 

Below is an illustration of a Simple IPC message: 

Simple IPC Message 

f \ 

0x00: Start of Header Mark (‘KROM’) 
0x04: Message ID 
0x08: Element Count 
OxOC: Data Count 

\_ J 

0x0010 Element[0].type 

Element[n].type 

Start of Data Mark (‘MORK’) 

Element[0].value 

Element[n].value 

End of Data Mark (‘BANG’) 


5.5. Services 

After discussing the connection between processes, we will now take a look at the services exposed by the 
different processes that are part of the Flash sandbox implementations. 

5.5.1. Chrome Sandbox Services 

The Chrome browser process provides sandboxed processes services that allow them to call security sensitive APIs 
(such as opening a file, registry key, etc.) provided that the API call is allowed by the policy. Generally, these 
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sandbox services are not directly invoked by the sandboxed process but are invoked indirectly via API interceptions 
in the sandboxed process. 


5.5.1.1. Connection 

In the context of Chrome Flash and Pepper Flash, the Chrome Sandbox services are callable from the sandboxed 
Flash plugin process via a Sandbox IPC connection: 


Flash Player Protected Mode For Chrome 
(Chrome Flash) 
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Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 



5.5.1.2. Services 

Chrome sandbox service handlers are methods of Dispatcher classes 
(http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/crosscall_server.h?view=markup) and each 
Dispatcher class handles a specific set of APIs. The table below lists the different Dispatcher classes in Chrome: 


Dispatcher Class 

Purpose 

FilesystemDispatcher 

Handles file system services. Handles forwarded filesystem-related 

NTDLL.DLL API calls. 

HandleDispatcher 

Handles handle duplication services. 

NamedPipeDispatcher 

Handles named pipe services. Handles forwarded CreateNamedPipeW() API 
calls. 

PolicyBase 

Special Dispatcher class. Among other things, the Sandbox IPC server uses 
PolicyBase to resolve actual Dispatcher class and the actual service handler 
routine to service the request. 

RegistryDispatcher 

Handles registry services. Handles forwarded NtOpenKeyf) and 

NtCreateKeyf) API calls. 

SyncDispatcher 

Handles synchronization (events) services. Currently handles forwarded 
CreateEventW() and OpenEventWf) API calls. 

ThreadProcessDispatcher 

Handles process and thread services. Currently handles forwarded 
CreateProcessWf), CreateProcessAf), and other thread/process-related API 
calls. 
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The source for the listed Dispatcher classes can be found in the “*_dispatcher.cc" files in Chromium's sandbox tree 
(http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/). 

Each service handler is registered as an IPCCall structure which is initialized in the constructor of each Dispatcher 
class. An IPCCall call structure contains the following information: 

• The IPC tag for the service handler - equivalent to a service ID, see Sandbox IPC section (5.4.1) for more 
information 

• The sequence and type of parameters expected by the service handler 

• The actual handler routine 

Below is an example IPCCall structure initialization: 


i FilesystemDispatcher::FilesystemDispatcher(PolicyBase* policy_base) 

: policy_base_(policy_base) { 

static const IPCCall create_params = { 

{IPC_NTCREATEFILE_TAG, WCHAR_TYPE, ULONG_TYPE, ULONG_TYPE, ULONG_TYPE, 
j ULONG_TYPE, ULONG^TYPE, ULONG_TYPE}, 

reinterpret_cast<CallbackGeneric>(&FilesystemDispatcher::NtCreateFile) 

}; 


Consequently, enumerating the Chrome Sandbox service handlers involves finding initializations of IPCCall 
structures. 

5.5.2. Chrome Plugin Services 

To support out-of-process NPAPI and PPAPI plugins such as Chrome Flash and Pepper Flash, the Chrome renderer 
and the Chrome browser process expose services which callable from out-of-process plugins. 

Generally, the services exposed by the browser process to the NPAPI/PPAPI plugin process are mostly for sending 
status or notification messages. On the other hand, the renderer process does most of the heavy lifting as it 
exposes services to the plugin process to support NPAPI and PPAPI calls. 

5.5.2.1. Connection 

In the case of Chrome Flash and Pepper Flash, the services exposed by the Chrome browser and the Chrome 
renderer process to the Flash plugin processes are callable via two separate Chromium IPC connections. A third 
Chromium IPC connection is employed by the renderer process to communicate with the browser process. In the 
context of plugins, the browser-renderer channel is used for executing privileged plugin service requests in the 
context of the browser process. 

The diagrams below show how the Flash plugin process, the Chrome browser and the Chrome renderer process 
are interconnected via Chromium IPC. 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 
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As mentioned earlier in the Chromium IPC section (5.4.2), the square boxes represent the Listener class which 
handles the IPC connection in each process. The Listener classes dispatch the IPC messages to the appropriate 
service handlers or routes the IPC message to other Listener classes which will handle the IPC message. 

5.5.2.2. Services (Out-of-Process NPAPI Plugin) 

The table below lists the different services exposed by the Chrome renderer and Chrome browser process to out- 
of-process NPAPI plugins. The listener column represents the name of the Listener class which handles the 
dispatching of the IPC message to the appropriate service handler. The message column represents names of the 
message classes which are used by the aforementioned Listener classes for selecting and invoking the appropriate 
service handler. 


Message 

Sent To 

Listener 

Purpose 

PluginProcessHostMsg_* 

Browser 

PluginProcessHost 

Sending plugin status or notifications 
to the browser process. 

PluginHostMsg_* 

Renderer 

PluginChannelHost 

WebPluginDelegateProxy 

Support services for NPAPI NPN_* 
calls. 




The renderer uses the services 
exposed by the browser process (via 
the browser-renderer channel) to 
handle privileged NPAPI service 
requests. 

NPObjectMsg_* 

Renderer/ 

Plugin 

NPObjectStub 

Marshalling NPObjects [15] between 
the plugin process and the renderer 
process. 


5.5.2.3. Services (Out-Of-Processes PPAPI Plugin) 

The table below lists the different services exposed by the Chrome renderer and Chrome browser process to out- 
of-process PPAPI plugin processes. 


Message 

Sent To 

Listener 

Purpose 

PpapiHostMsg_* 

Browser 

PpapiPluginProcessHost 

Sending plugin status or notification to the 
browser process. 

PpapiHostMsg_* 

Renderer 

Subclasses of InterfaceProxy 

PPAPI services. PPAPI services are exposed 
by a process via interface proxies 
(InterfaceProxy, 

http://src. chromium.org/viewvc/chrome/tr 
unk/src/ppa pi/proxy/in terface_proxy. h ?vie 
w=markup). 




InterfaceProxy is actually a subclass of the 
Listener class and thus have an 
OnMessageReceivedf) method which 
dispatches the PPAPI IPC messages to the 
appropriate service handler. 




The renderer uses the services exposed by 
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the browser process (via the browser- 
renderer channel) to handle privileged 
PPAPI service requests. 


Below are some examples of PPAPI interface proxies along with the corresponding messages classes used by the 
interface proxies for dispatching the PPAPI IPC messages to the actual service handlers: 


Message 

Interface Proxy 

Purpose 

PpapiHostMsg__PPBAudio_* 

PPB_Audio_Proxy 

Audio services 

PpapiHostMsg_PPBFileChooser_* 

PPB_FileChooser_Proxy 

Open/save dialog services 

PpapiHostMsg_PPBFilelO_* 

PPB_FilelO_Proxy 

File I/O services 

PpapiHostMsg_PPBFIashClipboard_* 

PPB_Flash_Clipboard_Proxy 

Clipboard services 

PpapiHostMsg_PPBVideoCapture_* 

PPB_VideoCapture_Proxy 

Video capture services 


The sources of PPAPI interface proxies are found in the Chromium source tree under “src/ppapi/proxy" 
(http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/proxy/) and their names are formatted as "*_proxy.cc ". 

5.5.3. Chrome Flash Broker Services 

Chrome Flash includes a separate broker process which exposes additional services to the sandboxed Flash plugin 
process. Example of the services exposed by the Chrome Flash broker includes displaying an open/save file dialog 
and launching the Flash Player settings manager. 

5.5.3.1. Connection 

The services exposed by the Flash broker process are callable from Flash plugin process via a Simple IPC 
connection: 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



5.5.3.2. Services 

The table below lists the type of services exposed by the Chrome Flash broker to the Flash plugin process. The 
code for these services is located in the gcswf32.dll binary. 


Service 

Purpose 

Dialog Services 

Opening an open/save file dialog. 

Filesystem Services 

Brokering calls to FindFirstFileW(), FindNextFileWf), CreateFileW(), 
MoveFileExWf) and CreoteDirectoryW(). 

'LM" Services 

Services for downloading and launching signed content. 

Memory mapping and Mutant Services 

Brokering calls to CreoteFileMoppingW() and CreateMutexWf). 

Network Services 

Brokering calls to WININET APIs. 

Miscellaneous Services 

Such as launching the Flash settings manager. 
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5.5.4. Firefox Flash Plugin Container Services 

The privileged plugin container process in Firefox exposes services that are callable from the sandboxed Flash 
plugin process. These exposed services are mainly used for proxying NPAPI calls between the Firefox browser 
process and the sandboxed Flash plugin process. 

5.5.4.1. Connection 

The services exposed by the plugin container process are callable from the Flash plugin process via a Chromium IPC 
connection: 

Flash Player Protected Mode For Firefox 
(Firefox Flash) 



The pipe name used for the Chromium IPC connection is formatted as 
"\\.\pipe\chrome.Flash%plugin_container_pid%.%p.%d" . The IPC connection is handled by the NPAPIHostChonnel 
Listener class in the plugin container process, while the IPC connection is handled by the NPAPIPIuginChannel 
Listener class in the Flash plugin process. 

Additionally, as shown in the diagram, a separate Chromium IPC connection exists between the Firefox browser 
process and the plugin container. This Chromium IPC connection is used for forwarding NPAPI calls between the 
browser process and the plugin container process. On a high-level, communication via this IPC connection are 
governed by Mozilla's Inter-process communication Protocol Definition Language (IPDL) [16], on a low-level, the 
actual messages are also sent via Chromium IPC. More information about Firefox's multi-process architecture can 
be found on Mozilla's Electrolysis project page [17]. 
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5.5.4.2. Services 

The table below lists the services exposed by the privileged plugin container to the sandboxed Flash plugin 
process. The code for these services is located in the NPSWF32.dll binary. 


Message Type 

Sent To 

Listener 

Purpose 

NPAPIHostChannel 

Messages 

Plugin Container 

NPAPIHostChannel 

Mostly for proxying NPAPI A/P/V_* APIs from 
the Flash plugin process to the browser 
process. 

NPN_* APIs proxied by NPAPIHostChannel 
are those that do not require a plugin 
instance (e.g. NPN_Getlntldentifier() and 
NPN_ ReloadPluginsf)). 

NPAPIPIuginProxy 

Messages 

Plugin Container 

NPAPIPIuginProxy 

Mostly for proxying NPAPI NPN_* APIs from 
the Flash plugin process to the browser 
process. 

NPN_* APIs proxied by NPAPIPIuginProxy 
are those that require a plugin instance (e.g. 
NPN_GetURL() and NPN_PostURL()). 

Various window-related services are also 
exposed by the plugin container to the Flash 
plugin process via the NPAPIPIuginProxy 
messages. 

NPObject Messages 

Plugin Container 
Flash Plugin 

NPObjectStub 

Proxying NPObject calls between the Flash 
plugin process and the browser process. 


5.5.5. Firefox Flash Broker Services 

The services exposed by the Firefox Flash broker can be divided into three groups: 


1. Sandbox Services 

2. Flash Services 

3. Permission Services 


The Sandbox services are equivalent to the Chrome Sandbox services (discussed in 5.5.1). Specifically, they handle 
forwarded API calls from the Flash plugin process. Flash services are additional services exposed to the Flash plugin 
such as displaying an open/save dialog and launching the Flash Player settings manager. Permission services are 
services for managing access permissions of the sandboxed Flash plugin process. 

5.5.5.1. Connection 

The Sandbox and Flash services exposed by the Flash broker process are callable from the sandboxed Flash plugin 
process via a Sandbox IPC connection. The permission services exposed by the Flash broker are callable from the 
plugin container via a Chromium IPC connection: 
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Flash Player Protected Mode For Firefox 
(Firefox Flash) 



The name of the IPC pipe used in the Chromium IPC connection between the plugin container and the Flash broker 
is formatted as "\\.\pipe\chrome.Flash%plugin_container_pid%.%p.%d'' . The Chromium IPC connection is handled 
by the PermissionsHostChonnel Listener class in the plugin container process, while the Chromium IPC connection 
is handled by the PermissionsBrokerChannel Listener doss in the Flash broker process. 

5.5.5.2. Services (Sandbox And Flash Services) 

The table below lists the Sandbox and Flash services exposed by the Flash broker to the Flash plugin process. The 
code for these services is located in the FlashPlayerPlugin.exe binary. By using the RTTI information embedded in 
FloshPlayerPlugin.exe binary in addition to referencing the Chromium code, we were able to recover the names of 
the Dispatcher classes. 


Dispatcher Class 

Purpose 

FilesystemDispatcher 

Handles file system services. Handles forwarded filesystem-related 
NTDLL.DLL API calls. 

MutantDispatcher 

Flandles synchronization (mutant) services. Flandles forwarded 
NtCreateMutant() and NtOpenMutantf) API calls. 

NamedPipeDispatcher 

Flandles named pipe services. Flandles forwarded CreoteNomedPipeW() 
API calls. 

PolicyBase 

Special dispatcher class. Among other things, the Sandbox IPC server uses 
PolicyBase to resolve actual dispatcher class and the actual handler 
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routine to service the request. 

RegistryDispatcher 

Flandles registry services. Flandles forwarded NtOpenKeyf) and 
NtCreateKeyO API calls. 

SandboxBrokerServerDispatcher 

Miscellaneous broker services. Flandles services which are not covered by 
the other dispatcher classes such as launching the Flash Player settings 
manager. Has interesting service handler routines and is a large attack 
surface due to the number of its service handler routines. 

SandboxVideoCaptureDispatcher 
(possible name) 

Flandles video capture services. 

SandboxClipboardDispatcher 

Handles clipboard services. Mostly handles forwarded clipboard-related 
USER32.DLL API calls. 

SandboxCryptDispatcher 

Handles cryptographic services. Mostly handles forwarded crypto-related 
SECUR32.DLL/SSPICLI.DLL and CRYPT32.DLL API calls. 

SandboxPrintDispatcher 

Flandles printing services. 

SandboxWininetDispatcher 

Flandles WININET services. Mostly handles forwarded WININET.DLL API 
calls. 

SectionDispatcher 

Flandles section object services. Currently handles forwarded 
NtCreateSectionf) and NtOpenSectionf) API calls. 

SyncDispatcher 

Flandles synchronization (events) services. Currently handles forwarded 
CreateEventWf) and OpenEventW() API calls. 

ThreadProcessDispatcher 

Flandles process and thread services. Currently handles forwarded 
CreateProcessW(), CreateProcessAf), and other thread/process-related 
API calls. 


5.5.5.3. Services (Permission Services) 

The table below lists the permission services exposed by the Flash broker process to the plugin container process. 
The code for these services is located in the FloshPloyerPlugin.exe binary. 


Message 

Sent to 

Listener 

Purpose 

PermissionsBrokerChannel 

Messages 

Flash Broker 

PermissionsBrokerChannel 

As of Firefox Flash 11.3, 
PermissionBrokerChannel messages 
are used for granting or denying the 
job object that the sandboxed Flash 
plugin process is associated to 
access to a window handle. 
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5.6. Policy Engine 

The policy engine allows the broker to specify exceptions to the default restrictions imposed in the sandbox. These 
exceptions, or whitelist rules, allows the broker to grant the sandbox process access to certain named objects, 
bypassing the sandbox restrictions. 

5.6.1. Adding policies 

The policy engine for all three implementations is derived from Chrome sandbox's policy engine so they share a lot 
in common. One of these is the way a policy is added. Policies are added programmatically using the 
sandbox::PolicyBase::AddRule() function. This function takes the following format: 


| AddRule(subsystem, semantics, pattern) 


The subsystem parameter indicates the Windows system the rules apply. The semantics parameter indicates the 
permission that will be applied to the file name/path, registry name, etc. that matches the pattern expression. 

The subsystems and semantics used are different for Firefox Flash and the sandboxes from Chrome, and are 
derived from that of Adobe Reader X's sandbox. Here are the subsystems and semantics for Firefox Flash: 


Subsystem 

Description 

SUBSYS_FILES 

Creation and opening of files and pipes. 

SU BSYS_N AM ED_PI PES 

Creation of named pipes. 

SU BSYS_PROCESS 

Creation of child processes. 

SUBSYS_REGISTRY 

Creation and opening of registry keys. 

SUBSYS_SYNC 

Creation of named sync objects. 

SUBSYS_MUTANT 

Creation and opening of mutant objects. 

SUBSYS_SECTION 

Creation and opening of section objects. 


Semantics 

Description 

FILES_ALLOW_ANY 

Allows open or create for any kind of access that the file system supports. 

FILES_ALLOW_READONLY 

Allows open or create with read access only. 

FILES_ALLOW_QUERY 

Allows access to query the attributes of a file. 

FILES_ALLOW_DIR_ANY 

Allows open or create with directory semantics only. 

NAMEDPIPES_ALLOW_ANY 

Allows creation of a named pipe. 

PROCESS_MIN_EXEC 

Allows creation of a process with minimal rights over the resulting process 
and thread handles. No other parameters besides the command line are 
passed to the child process. 
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PROCESS_ALL_EXEC 

Allows the creation of a process and return fill access on the returned 
handles. This flag can be used only when the main token of the sandboxed 
application is at least INTERACTIVE. 

EVENTS_ALLOW_ANY 

Allows the creation of an event with full access. 

EVENTS J\LLOW_READONLY 

Allows opening an event with synchronize access. 

REG_ALLOW_READONLY 

Allows read-only access to a registry key. 

M UTANT_ALLOW_ANY 

Allows creation of a mutant object with full access. 

SECTION_ALLOW_ANY 

Allows read and write access to a section. 

REG_ALLOW_ANY 

Allows read and write access to a registry key. 


Subsystems and semantics for Chrome Flash and Pepper Flash are derived directly from Chrome sandbox's. Flere 
are the subsystems and semantics for both Chrome Flash and Pepper Flash: 


Subsystem 

Description 

SUBSYS_FILES 

Creation and opening of files and pipes. 

SU BSYS_N AM ED_PI PES 

Creation of named pipes. 

SUBSYS_PROCESS 

Creation of child processes. 

SUBSYS_REGISTRY 

Creation and opening of registry keys. 

SUBSYS_SYNC 

Creation of named sync objects. 

SUBSYS_HANDLES 

Duplication of handles to other processes. 


Semantics 

Description 

FILES_ALLOW_ANY 

Allows open or create for any kind of access that the file system supports. 

FILES_ALLOW_READONLY 

Allows open or create with read access only. 

FILES_ALLOW_QUERY 

Allows access to query the attributes of a file. 

FILES_ALLOW_DIR_ANY 

Allows open or create with directory semantics only. 

NAMEDPIPES_ALLOW_ANY 

Allows creation of a named pipe. 
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PROCESS_MIN_EXEC 

Allows creation of a process with minimal rights over the resulting process 
and thread handles. No other parameters besides the command line are 
passed to the child process. 

PROCESS_ALL_EXEC 

Allows the creation of a process and return fill access on the returned 
handles. This flag can be used only when the main token of the sandboxed 
application is at least INTERACTIVE. 

EVENTS_ALLOW_ANY 

Allows the creation of an event with full access. 

EVENTS_ALLOW_READONLY 

Allows opening an event with synchronize access. 

REG_ALLOW_READONLY 

Allows read-only access to a registry key. 

REG_ALLOW_ANY 

Allows read and write access to a registry key. 

HAN DLES_DU P_ANY 

Allows duplicating of handles opened with any access permissions. 

HANDLES_DUP_BROKER 

Allows duplicating handles to the broker process. 


5.6.2. Admin-configurable policies 

In Firefox Flash, it is possible to add custom policies through a configuration file. This allows the administrator to 
set whitelists that bypasses the restrictions imposed by the sandbox. The policy file is enabled by setting the 
ProtectedModeBrokerWhitelistConfigFile option to 1 in mms.cfg. The policy file is named 
ProtectedModeWhitelistConfig.txt and should be placed in %WINDIR%\System32\Macromed\Flash for 32-bit 
Windows, and %WINDIR%\SysWow64\Macromed\Flash for 64-bit Windows. 

Each policy rule takes the format of: 


POLICY_RULE_TYPE = pattern string 


The POLICY_RULE_TYPE is derived from the semantics and can be any of the following: 


Policy Rule 

Description 

FILES_ALLOW_ANY 

Allows open or create for any kind of access that the file system supports. 

FILES_ALLOW_DIR_ANY 

Allows open or create with directory semantics only. 

NAMEDPIPES_ALLOW_ANY 

Allows creation of a named pipe. 

PROCESS_ALL_EXEC 

Allows the creation of a process and return full access on the returned 
handles. This flag can be used only when the main token of the sandboxed 
application is at least INTERACTIVE. 

EVENTS_ALLOW_ANY 

Allows the creation of an event with full access. 

REG ALLOW ANY 

Allows read and write access to a registry key. 
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M UTANT_ALLOW_ANY 

Allows creation of a mutant object with full access. 

SECTION J\LLOW_ANY 

Allows read and write access to a section. 


The pattern string is similar to the pattern parameter in the hard-coded policies and denotes file names, paths, 
registry locations, etc. 

5.7. Summary: Sandbox Mechanisms 

After discussing each Flash sandbox mechanism, as a summary, this section will discuss how all the sandbox 
mechanisms are interconnected. 

5.7.1. Flash Player Protected Mode For Chrome (Chrome Flash) 

In Chrome Flash, the sandboxed Flash plugin process connects to the following processes: 

• Chrome browser process via Sandbox IPC and Chromium IPC 

• Chrome renderer process via Chromium IPC 

• Flash broker process via Simple IPC 

API calls are intercepted in the Flash plugin process and are forwarded to the Chrome browser process via the 
Sandbox IPC connection; these forwarded API calls are first evaluated by the policy engine against the sandbox 
policies. For NPAPI calls, the Flash plugin process invokes the NPAPI support services exposed by the renderer 
process. Furthermore, the Flash plugin process also uses the additional services exposed by the Flash broker 
process. 

The diagram below shows how all the sandbox mechanisms are interconnected in Chrome Flash. 
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Flash Player Protected Mode For Chrome 
(Chrome Flash) 



5.7.2. Flash Player Protected Mode For Chrome Pepper (Pepper Flash) 

In Pepper Flash, the sandboxed Flash plugin process connects to the following processes: 

• Chrome browser process via Sandbox IPC and Chromium IPC 

• Chrome renderer process via Chromium IPC 

APIs calls are intercepted in the Flash plugin process and are forwarded to the Chrome browser process via the 
Sandbox IPC connection; these forwarded API calls are first evaluated by the policy engine against the sandbox 
policies. For PPAPI calls, the Flash plugin process invokes the PPAPI services exposed by the renderer process. Since 
the PPAPI services provide adequate capabilities to the Flash plugin process, there is no need for an additional 
Flash broker. 

The diagram below shows how all the sandbox mechanisms are interconnected in Pepper Flash. 
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Flash Player Protected Mode For Chrome Pepper 
(Pepper Flash) 



5.7.3. Flash Player Protected Mode For Firefox (Firefox Flash) 

In Firefox Flash, the sandboxed Flash plugin process connects to the following processes: 

• Plugin container process via Chromium IPC 

• Flash broker process via Sandbox IPC 

APIs calls are intercepted in the Flash plugin process and are forwarded to the Flash broker process via the 
Sandbox IPC connection; these forwarded API calls are first evaluated by the policy engine against the sandbox 
policies. In addition to servicing forwarded API calls, the Flash broker process also exposes additional services to 
the Flash plugin process. Furthermore, the Flash broker process additionally exposes permission services which 
grant/deny the sandboxed Flash plugin process access to resources. These permission services are exposed by the 
Flash broker process to the plugin container process. And for NPAPI calls, the Flash plugin process invokes the 
NPAPI services exposed by the plugin container process which in turn proxies the NPAPI calls to the browser 
process. 

The diagram below shows how all the sandbox mechanisms are interconnected in Firefox Flash. 
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Flash Player Protected Mode For Firefox 
(Firefox Flash) 
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6. Sandbox Limitations 

In this section, we will discuss the limitations and weaknesses of the three sandbox implementations. We will focus 
on the things that malicious code can still do when running inside the sandbox, in spite of the sandbox restrictions. 

6.1. File System Read Access 

Firefox Flash allows read access to all files that are accessible from the user's account. This is partly a result of the 
sandbox process token still having access to some files (such as those accessible to the Everyone and Users group), 
but more importantly, there is a hard-coded policy rule that allows read access to all files: 


SubSystem=SUBSYS_FILES 

Semantics=FILES_ALLOW_READONLY 

Pattern="*" 


We can assume that above policy rule was added for compatibility reasons. Flowever, the security implication of 
this weakness is that it would allow malicious code running in the sandbox to read the user's documents, source 
codes, application configuration/data files (which may contain encrypted password or password hashes), and 
other sensitive files. 

This weakness also allows an attacker to read the policy file " ProtectedModeWhitelistConfig.txt ", which contains 
user configured custom policies. This can give attackers an idea of what exceptions from the sandbox restrictions 
are in effect, and may allow them to craft more effective attacks subsequently. 

Chrome Flash also allows read access as much as Firefox Flash does, not by any explicit policy rules but due to the 
sandbox process token still having read access to files. 

In contrast to the other two implementations, Pepper Flash does not allow any direct file access at all. 

6.2. Registry Read Access 

Firefox Flash also allows read access to registry keys that are accessible from the user's account. This is partly a 
result of the sandbox process token still having access to some registry keys (such as those accessible to the 
Everyone and Users group), but more importantly, there are several hard-coded policy rules that allow read access 
to major registry hives: 


SubSystem=SUBSYS_REGISTRY 
S emantic s=REG_ALLOW_READONLY 
| Pattern= M HKEY_CLASSES_ROOT* n 

SubSystem=SUBSYS_REGISTRY 
S emantic s=REG_ALLOW_READONLY 
Pattern= M HKEY_CURRENT_USER*” 

SubSystem=SUBSYS_REGISTRY 
S emantic s=REG_ALLOW_READONLY 
Pattern="HKEY_LOCAL_MACHINE* 

SubSystem=SUBSYS_REGISTRY 
S emantic s=REG_ALLOW_READONLY 
| Pattern="HKEY_USERS*" 

| SubSystem=SUBSYS_REGISTRY 
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S emantic s=REG_ALLOW_READONLY 
Pattern="HKEY CURRENT CONFIG* 


Again, we can speculate that the above policies were added for compatibility reasons. This weakness would allow 
malicious code running in the sandbox to read system configuration information, get a list of installed applications, 
and retrieve application configuration/data (which may contain encrypted passwords or password hashes) and 
other sensitive information. In addition to the policies above, Firefox Flash also allows full access to certain Flash 
related registry keys. For example, full access is granted for any registry access to a key that matches the pattern 
HKEY_CURRENT_USER\Softwore\Macromeclio\Flosh Player*. 

Chrome Flash also allows read access to the major registry hives mentioned above. Flowever, it does not explicitly 
allow any other registry access. 

Pepper Flash on the other hand does not allow any registry access at all. 

6.3. Network Access 

A notable limitation in both Chrome Flash and Firefox Flash is their inability to restrict network access. This 
limitation would allow malicious code running in the sandbox process to send stolen information to a remote 
server. Another way to leverage this limitation is by connecting to and possibly exploiting internal systems which 
are accessible to the affected machine but are otherwise inaccessible if accessed from outside the internal 
network. This type of attack was already known in the pre-sandbox days, but it is interesting that it is still possible. 
Pepper Flash doesn't have this limitation as it disallows socket creation. 

6.4. Policy Allowed Write Access to Files/Folders 

A weakness we found researching Firefox Flash are the permissive policy rules that grant the sandbox process 
write access to certain folders and files, some of which are used by third party applications. If the writable 
folder/file is used by a certain application to store configuration information, it may be possible for malicious code 
running in the sandbox process to control the behavior of the application, which in turn could lead to further 
compromise of the system. 

The ability to create a local file with a controllable file name can also be leveraged by an attacker in the following 
use-cases: 

• Can be leveraged in exploiting a vulnerability in which successful exploitation requires the creation an 
attacker-controlled file with a predictable file name. 

• For multi-stage exploit payloads, an attacker can use the writable locations as a location to temporarily 
store a second stage payload library file which can then be loaded to the sandbox process. 

6.5. Clipboard Read/Write Access 

In Firefox Flash, programmatic read/write access is permitted on the clipboard which could be abused. This is 
because in addition to the clipboard read/write access restriction not being placed in the job object the sandbox 
process is assigned to, the SondboxClipboordDispotcher dispatcher class in the broker process also provides 
clipboard-related services which allow clipboard access in the context of the broker process. 

Chrome Flash also allows read/write access to the clipboard because no clipboard read/write access restriction is 
placed on the sandbox's job object. 
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Thus, for these two implementations it is possible for code running in the sandbox process to read the clipboard 
contents, which may contain sensitive information (such as passwords - if the user uses an insecure password 
manager that does not regularly clears the clipboard). Clipboard write access may also lead to other security issues 
such as arbitrary command injection, and if an application trusts the clipboard contents, it could also become an 
avenue for a sandbox escape - these are described by Tom Keetch in the paper “Practical Sandboxing on the 
Windows Platform" [18]. 

As usual, Pepper Flash does not have this weakness. 

6.6. Write Access To FAT/FAT32 Partitions 

Common to all three implementations is that they all allow write access to FAT/FAT32 partitions. Since FAT/FAT32 
partitions (still mostly used in USB flash drives) do not support security descriptors, it is possible for code running 
in the sandbox process to create or modify files located in partitions of these types. As a consequence, malicious 
code running in the sandbox process will be able to drop malicious files on FAT/FAT32 partitions which could in 
turn lead to propagation behaviors. An example of such propagation behavior is dropping a malicious EXE file and 
an autorun.inf file. 

6.7. Sandbox Limitation Comparison Table 

Flere's a comparison table for each sandbox's restrictions against some important objects: 


Chrome Flash 


Firefox Flash 


File System READ Access 
(%USERPROFILE%) 


Pepper Flash 


File System READ Access 
(%USERPROFILE%\Documents) 


File System READ Access 
(%APPDATA%) 


File System READ Access 
(%LOCALAPPDATA%) 


File System READ Access 
(%LOCALAPPDATA%\Temp) 


File System READ Access 
(%USERPROFILE%\AppData\LocalLow) 


File System READ Access 
(%SystemDrive%) 


File System READ Access 
(%SystemDrive%\Program Files) 


File System READ Access 
(%SystemDrive%\Program Files (x86)) 


DENIED 


DENIED 


DENIED 


DENIED 


DENIED 


DENIED 


DENIED 


DENIED 


File System READ Access 
(%SystemRoot%) 


DENIED 


File System WRITE Access 
(%USERPROFILE%) 


DENIED 


DENIED 


DENIED 


DENIED 


DENIED 


DENIED 


File System WRITE Access 
(%USERPROFILE%\Documents) 


DENIED 


DENIED 

DENIED 


DENIED 


File System WRITE Access 
(%APPDATA%) 


File System WRITE Access 


DENIED 


DENIED 


IBM Security Systems | ©2012 IBM Corporation 


















































































Digging Deep Into The Flash Sandboxes > Sandbox Limitations 


154 



6.8. Summary: Sandbox Limitations 

In this section we showed the various limitations and weaknesses of each sandbox. We can also safely conclude 
that among the three implementations, Pepper Flash offers the most restriction. 


While code running in the Flash sandboxes is severely limited in terms of what it can do, it is still possible to carry 
out information theft attacks by leveraging their current weaknesses and limitations. This is an important point to 
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remember because the result of an information theft attack can be devastating especially for businesses and 
governments. And by conveying the security implication of each limitation or weakness, we hope that we can 
create an awareness that users should still continue to be cautious when opening unsolicited documents even if 
the application they are using has sandboxing capabilities. 
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7. Sandbox Escape 

In this section, we will discuss the different ways that malicious code might use to escape the Flash sandboxes. This 
section starts with a discussion of generic escape methods and then moves to the discussion of attacking specific 
sandbox mechanisms to conduct a sandbox escape. Furthermore, most of the items discussed in this section are 
not specific to the Flash sandbox and can be applied to other sandbox implementations as well. 

As a side note, one important advantage for code already running in the sandbox process is that it already has the 
necessary information to perform a Data Execution Prevention (DEP) and Address Space Layout Randomization 
(ASLR) bypass when exploiting other applications running on the same system. The reason is that a system-wide 
value called the image bias which dictates the load address of DLLs is shared across processes and is computed 
only once per boot [19]. This means, that for example, code running in the sandboxed Flash plugin process can use 
the NTDLL.DLL and KERNEL32.DLL base in the sandboxed process when crafting a ROP sequence for the exploit to 
be used against a higher-privileged process. 

7.1. Local Elevation of Privilege (EoP) Vulnerabilities 

The first option when performing a sandbox escape is by exploiting local elevation of privilege (EoP) vulnerabilities. 
Exploiting local EoP vulnerabilities, especially those can result in arbitrary code execution in kernel mode are an 
ideal way to bypass all the restrictions set on sandboxed code. 

With multiple available interfaces to kernel-mode code such as system calls and Device objects which are 
accessible to a sandboxed process, we can expect that local EoP vulnerabilities will become more valuable as more 
and more critical applications are being sandboxed. An interesting discussion on kernel-mode vulnerabilities can 
be found in the presentation "There's a party at RingO, and you're invited" [20] by Tavis Ormandy and Julien 
Tinnes. 

7.2. Named Object Squatting Attacks 

Named object squatting is an attack involving a malicious application creating a named object that a target 
application is known to trust. In the context of a sandbox escape, code running in a compromised sandbox process 
can create a malicious named object and wait until a higher-privileged process uses the malicious named object. 

An example of named object squatting is an attack against Protected Mode Internet Explorer discussed by Tom 
Keetch in his presentation "Practical Sandboxing on the Windows Platform " [18]. 

7.3. IPC Message Parser Vulnerabilities 

Running in a privileged context and being the first code that touches potentially untrusted data from an IPC 
connection, the IPC message parser is one of the primary attack vectors in a sandbox implementation for 
conducting a sandbox escape. From an auditing perspective, the routines of interest are those that parse IPC 
message and those that deserialize IPC call parameters (especially complex parameters types). 

In section 5.4, we had discussed the different IPC implementations used by the different Flash sandboxes, all of 
them are open source, and thus, a source audit is possible. An interesting exercise is looking at security updates 
made in the public sources and then checking whether or not those security updates are propagated to the 
binaries released by Adobe - this also applies to other sandbox mechanisms as well. 

An example of IPC message parser vulnerability is the SkBitmap deserialization vulnerability discovered by Mark 
Dowd [14] in the Chrome sandbox. 
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7.4. Policy Vulnerabilities 

Permissive policies, particularly those that allow write access to a resource can also be used as a vector for 
sandbox escape. 

An example scenario would be write-allowed policies for registry keys - if a particular key has sub keys or entries 
that are used for sandbox configuration, the sandboxed code can potentially control the initialization of the 
sandbox and use it directly or indirectly to perform a sandbox escape. The same applies to write-allowed policies 
for files or folders - if a particular folder contains a configuration file used by a higher-privileged process, the 
behavior of the higher-privileged process can possibly be controlled by a sandboxed code and could possibly lead 
to a sandbox escape. Also, if a particular folder contains executable files, a sandboxed code can potentially 
overwrite the contents of the executable file so that when the executable file is spawned, an attacker-controlled 
code will be executed in a privileged context. 

Auditing for policy vulnerabilities involves enumerating all the policies in a sandbox implementation and 
specifically looking for policies that allow write access. Once all write allowed policies are enumerated, each write 
policy is then audited for potential escape by checking if the writable resource can affect the behavior of a higher- 
privileged application. 

7.5. Policy Engine Vulnerabilities 

Acting as a gatekeeper who decides which potentially sensitive actions are allowed or disallowed, the policy engine 
is another sandbox mechanism that can be leveraged to conduct a sandbox escape. 

Auditing for policy engine vulnerabilities involves looking for ways to bypass policy checks such as checking if there 
is lack of or insufficient canonicalization of resource names when performing policy checks. Additionally, auditing 
for memory corruption bugs may also yield results if there is complex preprocessing of resource names during 
policy checks. 

An excellent example of a policy engine vulnerability is CVE-2011-1353 [21, 22], a vulnerability we discovered (and 
also independently discovered by Zhenhua Liu [23] of Fortinet's Fortiguard Labs) in the policy engine of the Adobe 
Reader X sandbox. The vulnerability (since patched) is due to lack of canonicalization of a resource name when 
evaluating registry deny-access policies. In Reader X, there is a policy allowing full access to the sub keys of the 
registry key HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0: 


Subsystem: SUBSYS_REGISTRY 
Semantics: REG_ALLOW_ANY 

Pattern: HKEY CURRENT USER\Software\Adobe\Acrobat Reader\10.0\* 


However, one of the sub keys of the previously mentioned registry key is used by Reader X to store sandbox 
configuration. An example is the registry entry bProtectedMode under the Privileged subkey which is used by 
Reader X to determine whether to enable or disable the Reader X sandbox: 


HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\Privileged 
bProtectedMode = 0 (disabled), non-zero (enabled) 


Accordingly, a registry deny-access policy also exists to prevent access to the Privileged sub key: 

| Subsystem: SUBSYS_REGISTRY 

! _ 
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Semantics: REG_DENY 

Pattern: HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\Privileged* 


However, since there is lack of canonicalization of registry resource name when performing policy checks, simply 
modifying the registry resource name to contain additional back slashes such as: 


HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\\Privileged 


Will result in a bypass of the registry deny-access policy, thereby, allowing a sandboxed code to disable the Reader 
X sandbox. 

7.6. Service Vulnerabilities 

In the Services section (5.5), we discussed the different services exposed by different Flash sandbox processes. The 
services exposed by higher-privileged processes make up a large part of the attack surface in a sandbox 
implementation since they are many and run in a privileged context. 

Two examples of service vulnerability in a Flash sandbox implementation is CVE-2012-0724 and CVE-2012-0725 
[24, 25], two vulnerabilities we discovered (and also independently discovered by Fermin J. Serna of the Google 
Security Team). Both vulnerabilities exist in the Chrome Flash Broker and are similar in nature. 

CVE-2012-0724 and CVE-2012-0725 exist in two service handlers which are part of the Chrome Flash Broker 
Services (5.5.3) and are callable to the sandboxed Flash plugin process via Simple IPC (5.4.3). Essentially, the 
vulnerabilities were due to the service handlers accepting and fully trusting a pointer they received from the 
sandboxed Flash plugin process. The vulnerable service handlers including their corresponding Simple IPC message 
ID and parameters are as follows: 


Message ID 

Parameters 

Purpose 

0x2B 

VOIDPTR sec_func_table 

Broker a call to AcquireCredentialFlandlesA() 

0x2D 

VOIDPTR sec_func_table, 

Broker a call to FreeCredentialsFlandle() 


ULONG32 cred_handle_lower, 



ULONG32 cred_handle_upper 



Notice that in both service handlers, the first parameter is a pointer (sec_func_toble), and specifically, a pointer to 
a SecurityFunctionTableA [26] structure. Inside the service handlers, sec_func_table is fully trusted (no checks or 
further transformation is done) and is dereferenced to invoke SecurityFunctionTobleA.AcquireCredentiolsHondleA() 
and SecurityFunctionTobleA.FreeCredentiolsFlondle()\ 


Service 

0x2B AcquireCredentialsHandleA: | 

mov 

reg, [sec func table] 

; sec func table is fully controllable » 

call 

[reg+OCh] 

; sec func table->AcquireCredentialsHandleA() 



; reg+OCh is fully controllable! 
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Service 

0x2D FreeCredentialsHandle: | 

mov 

reg, [sec func table] ; 

sec func table is fully controllable | 

call 

[reg+lOh] ; 

sec func table->FreeCredentialsHandle() 


; 

reg+lOh is fully controllable! 


Since sec_func_toble is fully controllable, the address used in the call instruction is also fully controllable. With 
additional research work of figuring out how to implant data in the stack of the Flash broker process, and using 
one of the vulnerabilities to leak the stack address of the Flash broker to the sandboxed Flash plugin, and finally, 
with the possibility of predicting the address of APIs in the Flash broker process (as explained in the image bias 
side note), we were able to achieve arbitrary code execution in the Chrome Flash broker process. 

We expect that in the future, to accommodate new features, new services will continually need to be added to 
accommodate the new functionalities. 

7.7. Summary: Sandbox Escape 

Sandbox escape involves a sandboxed code exploiting a weakness in a higher-privileged process. The higher- 
privileged process can be a process which is a part of the operating system, another application or part of the 
sandbox implementation itself. Two prime examples of weaknesses that can lead to a sandbox escape are setting 
of permissive policies and improper handling of untrusted data provided by the sandboxed code. 

As sandboxes becomes more prevalent in critical applications, an attacker would now need a separate 
vulnerability, or in some cases, a few more vulnerabilities [27, 28] to execute code in an elevated privilege in order 
to install persistent malware in a target system. That being said, sandbox escape vulnerabilities will become more 
important and exploiting them will become a major part of sophisticated attacks targeting critical applications. 
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8. Conclusion 

In this paper we discussed three different implementations of the Flash Player sandbox. We have concluded that 
out of the three implementations, the one that offers the most security is Pepper Flash. As the current 
implementation still in the experimental phase, it still remains to be seen how well it would fare in the real world 
with its extreme restrictions. In our experience, it is still not stable enough for day to day use (e.g. YouTube 
videos). Fortunately, even the less restrictive Firefox Flash and Chrome Flash still offers substantial cost of 
exploitation. In fact, we haven't encountered any public exploits that fully exploits a Flash vulnerability through 
Firefox and Chrome since these sandbox implementations were released. 

Flowever, it does not mean that users should be complacent. As we have shown in this paper, there are still ways 
in which an attacker or malicious code can do damage in spite of running within the sandbox restrictions, and also 
that there are still many ways in which a determined attacker can possibly discover how to escape or bypass the 
sandboxes. We hope that through the discussion of the internal mechanisms, limitations, and weaknesses of these 
sandbox implementations, we have increased the reader's awareness regarding this topic. 

Finally, we hope that this paper will serve as an inspiration and useful resource for our fellow security researchers 
for digging more deeply into current and future sandbox implementations. 
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11. Appendix A: Evicted DLLs and Plugins 
11.1. Evicted DLLs In Firefox Flash 

(As of version 11.3.300.257) 


adialhk.dll 

acpiz.dll 

avgrsstx.dll 

babylonchromepi.dll 

btkeyind.dll 

cmcsyshk.dll 

cooliris.dll 

dockshellhook.dll 

googledesktopnetwork3.dll 

fwhook.dll 

hookprocesscreation.dll 

hookterminateapis.dll 

hookprintapis.dll 

imon.dll 

ioloHL.dll 

kloehk.dll 

lawenforcer.dll 

libdivx.dll 

Ivprcinj01.dll 

madchook.dll 

mdnsnsp.dll 

moonsysh.dll 

npdivx32.dll 

npggNT.des 

npggNT.dll 

oawatch.dll 

pavhook.dll 

pavshook.dll 

pavshookwow.dll 

pctavhook.dll 

pctgmhk.dll 

prntrack.dll 

radhslib.dll 

radprlib.dll 

rapportnikko.dll 

rlhook.dll 

rooksdol.dll 

rpchromebrowserrecordhelper.dll 

rpmainbrowserrecordplugin.dll 

r3hook.dll 

sahook.dll 

sbrige.dll 

sc2hook.dll 
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sguard.dll 

sm um32 .dll 

smumhook.dll 

ssldivx.dll 

syncorl l.dll 

systools.dll 

tfwah.dM_ 

ycwebcamerasource.ax 

wblind.dll 

wbhelp.dll 

winstylerthemehelper.dll 

11.2. Evicted DLLs In Chrome Flash and Pepper Flash 

(As of version 20.0.1132.43) 


adialhk.dll 

acpiz.dll 

avgrsstx.dll 

babylonchromepi.dll 

btkeyind.dll 

cmcsyshk.dll 

cmsetac.dll 

cooliris.dll 

dockshellhook.dll 

easyhook32.dll 

googledesktopnetwork3.dll 

fwhook.dll 

hookprocesscreation.dll 

hookterminateapis.dll 

hookprintapis.dll 

imon.dll 

ioloHL.dll 

kloehk.dll 

lawenforcer.dll 

libdivx.dll 

Ivprcinj01.dll 

madchook.dll 

mdnsnsp.dll 

moonsysh.dll 

mpk.dll 

npdivx32.dll 

npggNT.des 

npggNT.dll 

oawatch.dll 

owexplorer-10513.dll 

owexplorer-10514.dll 

owexplorer-10515.dll 

owexplorer-10516.dll 

owexplorer-10517.dll 
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owexplorer-10518.dll 

owexplorer-10519.dll 

owexplorer-10520.dll 

owexplorer-10521.dll 

owexplorer-10522.dll 

owexplorer-10523.dll 

pavhook.dll 

pavlsphook.dll 

pavshook.dll 

pavshookwow.dll 

pctavhook.dll 

pctgmhk.dll 

prntrack.dll 

protector.dll 

radhslib.dll 

radprlib.dll 

rapportnikko.dll 

rlhook.dll 

rooksdol.dll 

rpchromebrowserrecordhelper.dll 

r3hook.dll 

sahook.dll 

sbrige.dll 

sc2hook.dll 

sdhook32.dll 

sguard.dll 

smum32.dll 

smumhook.dll 

ssldivx.dll 

syncorll.dll 

systools.dll 

tfwah.dll 

wblind.dll 

wbhelp.dll 

winstylerthemehelper.dll 


11.3. Evicted Plugin DLLs In Chrome Flash 


rpmainbrowserrecordplugin.dll 


rpchromebrowserrecordhelper.dll 

rpchromelObrowserrecordhelper.dll 

ycwebcamerasource.ax 

CLRGL.ax 


IBM Security Systems | ©2012 IBM Corporation 












































